home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20020314-20021006 / 000424_jfathman@aol.com_Sun Oct 6 11:03:02 EDT 2002.msg < prev   
Text File  |  2020-01-01  |  3KB  |  70 lines
  1. Article: 13760 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!panix!newsfeed.mathworks.com!news-hog.berkeley.edu!ucberkeley!newsfeed.stanford.edu!postnews1.google.com!not-for-mail
  3. From: jfathman@aol.com (Jim)
  4. Newsgroups: comp.protocols.kermit.misc
  5. Subject: YModem
  6. Date: 5 Oct 2002 19:12:51 -0700
  7. Organization: http://groups.google.com/
  8. Lines: 52
  9. Message-ID: <6dfb5332.0210051812.463a13dc@posting.google.com>
  10. NNTP-Posting-Host: 198.81.21.23
  11. Content-Type: text/plain; charset=ISO-8859-1
  12. Content-Transfer-Encoding: 8bit
  13. X-Trace: posting.google.com 1033870371 30440 127.0.0.1 (6 Oct 2002 02:12:51 GMT)
  14. X-Complaints-To: groups-abuse@google.com
  15. NNTP-Posting-Date: 6 Oct 2002 02:12:51 GMT
  16. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13760
  17.  
  18. Hello,
  19.  
  20. For many years, I have been using YModem for serial and modem based
  21. file transfers in an embedded product.  Now I am adding a TCP/IP
  22. network interface, while preserving the YModem functionality.
  23.  
  24. I have the network interface working, but I have encountered a very
  25. odd problem.  The YModem support in Kermit 95+ v2.0 and three other
  26. commercial telnet/YModem products I have tried all produce a YModem
  27. initial packet header that, based on my reading of the protocol spec,
  28. is non-compliant.
  29.  
  30. Chuck Forsberg's spec (granted it is old, dated 9-11-86, but that is
  31. the newest I have found) specifies the format of the initial YModem
  32. packet as:
  33.  
  34.   SOH 00 FF foo.c NUL[123] CRC CRC
  35.  
  36. But when I use Kermit or the other three commercial telnet/YModem
  37. products to send a file, they *all* produce an additional 0xFF before
  38. the file name.
  39.  
  40. To rule out my embedded software, I wrote a simple socket server under
  41. Linux that accepts connection requests, issues 'C' prompts to make
  42. Kermit YModem send happy, and hex dumps the incoming bytes from the
  43. Kermit YModem send.  As with my embedded product, Kermit YModem send
  44. produces:
  45.  
  46. [0001] 0x01 = .   <-- SOH
  47. [0002] 0x00 = .   <-- sequence number
  48. [0003] 0xff = .   <-- seq num complement
  49. [0004] 0xff = .   <-- !! what is this ? !!
  50. [0005] 0x6a = j   <-- start of file name
  51. [0006] 0x6d = m
  52. [0007] 0x66 = f
  53. [0008] 0x2e = .
  54. [0009] 0x6a = j
  55. [0010] 0x6d = m
  56. [0011] 0x66 = f
  57. [0012] 0x00 = .
  58. <etc.>
  59.  
  60. Kermit and three other commercial products can't all be wrong.  What
  61. am I missing here?  Is there a newer YModem spec that I just can't
  62. find?  Are the rules for YModem over TCP different somehow than YModem
  63. over serial/modem?
  64.  
  65. Any guidance would be most helpful.
  66.  
  67. Thanks.
  68.  
  69. Jim
  70.